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BACKGROUND OF THE INVENTION 

Field of the Invention 

5 [0001] This invention is related to the field of application performance management and, 
more particularly, to usage measurement and cost allocation. 

Description of the Related Art 

10 [0002] In the information technology (IT) departments of modern organizations, one of 
the biggest challenges is meeting the increasingly demanding service levels required by 
users. With more and more applications directly accessible to customers via automated 
interfaces such as the world wide web, "normal" business hours for many enterprises are 
now 24 hours a day, 7 days a week. The need for continuous availability and 

15 performance of applications has created complex, tiered IT infrastructures which often 
include web servers, middleware, networking, database, and storage components. These 
components may be from different vendors and may reside on different computing 
platforms. A problem with any of these components can impact the performance of 
applications throughout the enterprise. 

20 

[0003] The performance of key applications is a function of how well the infrastructure 
components work in concert with each other to deliver services. With the growing 
complexity of heterogeneous IT environments, however, the source of performance 
problems is often unclear. Consequently, application performance problems can be 
25 difficult to detect and correct. Furthermore, tracking application performance manually 
can be an expensive and labor-intensive task. Therefore, it is usually desirable that 
application performance management tasks be automated. 

[0004] Automated tools for application performance management may assist in providing 
30 a consistently high level of performance and availability. These automated tools may 
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result in lower costs per transaction while maximizing and leveraging the resources that 
have already been spent on the application delivery infrastructure. Automated tools for 
application performance management may give finer control of applications to IT 
departments. Application performance management tools may enable IT departments to 
5 be proactive and fix application performance issues before the issues affect users. 
Historical performance data collected by these tools can be used for reports, trending 
analyses, and capacity planning. By correlating this collected information across 
application tiers, application performance management tools may provide actionable 
advice to help IT departments solve current and potential problems. 

10 

[0005] For many organizations, measurement of resource utilization is only a first step. 
To justify investment in IT and otherwise promote accountability, an organization may 
desire to measure usage and allocate (or "charge back") the costs of resources to those 
within the organization who are responsible for usage of those resources. Prior 

15 approaches have generally used "head counts" (e.g., number of software licenses), 
arbitrary percentages, fixed "taxation" models, and similar allocation models. As 
different entities within an organization may share access to various system resources, 
these allocation models may fail to accurately reflect actual usage of particular system 
resources by particular entities. It is desirable to provide improved systems and methods 

20 for measuring, reporting, and analyzing usage patterns as well as enabling usage-based 
cost allocation of system resource usage. 
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SUMMARY OF THE INVENTION 



[0006] Various embodiments of a system and method described herein may provide 
system resource usage and usage-based cost . The method may include determining a 

5 cost for each of a plurality of system resources in a computer system. A cost allocation 
method may be determined for each of the system resources. Resource usage by a 
particular organizational unit may be determined for each of the system resources. The 
cost of resource usage by the organizational unit may be programmatically determined 
based on the cost for each of the system resources, the cost allocation method for each of 

10 the system resources, and the resource usage by the organizational unit for each of the 
system resources. 
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BRIEF DESCRIPTION OF THE DRAWINGS 



[0007] Figure 1 illustrates an exemplary performance management system in which 
embodiments of a system and method for performance management may be implemented. 

5 

[0008] Figure 2 illustrates components of an exemplary computer system with which 
embodiments of a system and method for performance management may be implemented. 

[0009] Figure 3 illustrates components of a performance management system including a 
10 business efficiency manager (BEM) according to one embodiment. 

[0010] Figure 4 illustrates components of a BEM server according to one embodiment. 

[0011] Figure 5 is a flowchart which illustrates a method of cost allocation in a 
15 performance management system according to one embodiment. 

[0012] Figure 6 is a screenshot which shows an example of an application usage view in 
a resource workspace according to one embodiment. 

20 [0013] Figure 7 is a screenshot which shows an example of a usage over time view in a 
resource workspace according to one embodiment. 

[0014] Figure 8 is a screenshot which shows an example of a usage of features view in a 
resource workspace according to one embodiment. 

25 

[0015] Figure 9 is a screenshot which shows an example of a new users view in a 
resource workspace according to one embodiment. 

[0016] Figure 10 is a screenshot which shows an example of a usage summary view in an 
30 organizational unit workspace according to one embodiment. 
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[0017] Figure 1 1 is a screenshot which shows an example of an application usage view in 
an organizational unit workspace according to one embodiment. 

5 [0018] Figure 12 is a screenshot which shows an example of a usage of features view in 
an organizational unit workspace according to one embodiment. 

[0019] Figure 13 is a screenshot which shows an example of a summary view in a cost 
workspace according to one embodiment. 

10 

[0020] Figure 14 is a screenshot which shows an example of an application cost view in a 
cost workspace according to one embodiment. 

[0021] Figure 15 is a screenshot which shows an example of an organizational unit cost 
15 view in a cost workspace according to one embodiment. 

[0022] Figure 16 is a screenshot which shows an example of an OU cost analysis view in 
a cost workspace according to one embodiment. 

20 [0023] Figure 17 is a screenshot which shows an example of a summary view in a 
licenses workspace according to one embodiment. 

[0024] Figure 18 is a screenshot which shows an example of a license utilization view in 
a licenses workspace according to one embodiment. 

25 

[0025] Figure 19 is a screenshot which shows an example of an unlicensed usage view in 
a licenses workspace according to one embodiment. 

[0026] While the invention is described herein by way of example for several 
30 embodiments and illustrative drawings, those skilled in the art will recognize that the 
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invention is not limited to the embodiments or drawings described. It should be 
understood, that the drawings and detailed description thereto are not intended to limit the 
invention to the particular form disclosed, but on the contrary, the intention is to cover all 
modifications, equivalents and alternatives falling within the spirit and scope of the 
5 present invention as defined by the appended claims. As used throughout this 
application, the word "may" is used in a permissive sense (i.e., meaning "having the 
potential to"), rather than the mandatory sense (i.e., meaning "must"). Similarly, the 
words "include," "including," and "includes" mean "including, but not limited to." 
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DETAILED DESCRIPTION OF EMBODIMENTS 



[0027] Various embodiments of a business efficiency manager (BEM) may provide 
usage-based charge-back using usage data from a performance management system. In 
5 other words, the BEM may provide for the allocation of costs for usage of particular 
system resources to particular units within an organization. System resources may 
include software (e.g., applications), hardware (e.g., CPU, memory), storage, network 
resources, or substantially anything whose consumption by one or more users is 
measurable. Organizational units may include individual users, groups of users, 
10 departments, divisions, subdivisions, geographical locales, or any other suitable groups of 
users within an organization. 

[0028] A performance management system may include one or more software programs 
for application performance management and resource usage measurement. By 

15 continuously monitoring key components and/or applications of computer systems, the 
performance management system may collect performance and usage data. Using this 
data, the performance management system may act to detect and correct performance 
problems among applications and other system components. The performance 
management system may provide performance management in a variety of stages, such 

20 as: identification of symptoms that could indicate a performance problem, identification 
of sources or locations of problems, discovery of root causes of problems, 
recommendation of measures to address the root causes and improve performance, and 
verification that the measures have achieved desired goals. By defining baselines for 
"normal" application behavior, the performance management system may automatically 

25 detect degradation based on those established norms. 

[0029] In one embodiment, the performance management system may be implemented in 
a variety of versions, each of which is customized for management of a particular class of 
target software: e.g., various products from PeopleSoft, Inc.; Oracle® database 
30 management software and related applications; web-based applications; SAP®; various 
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products from Siebel Systems, Inc.; ClarifyCRM™; J2EE™; and other suitable targets. 
Furthermore, each of the versions may be implemented on one or more computing 
platforms (e.g., Solaris running on Sun Microsystems™ hardware, or a Microsoft 
Windows® OS running on Intel-based hardware). As used herein, the term "performance 
5 management system" is intended to include all of these disparate, customized software 
programs. 

[0030] Figure 1 is an architecture diagram of a performance management system 100 in 
an exemplary configuration. As illustrated in Figure 1, the performance management 

10 system 100 may include components such as a measurement component 102 (including 
various agent modules 104a, 106a, and 108a), a discovery component 112, a console 
component 120, and a performance warehouse 110. The various components of the 
performance management system 100 may reside on the same computer system, on 
different computer systems, or on an arbitrary combination of computer systems. An 

15 exemplary computer system is illustrated in Figure 2. 

[0031] In one embodiment, the measurement component 102 uses agent software to 
capture performance metrics on servers running target applications. The measurement 
component 102 may provide a "breadth-wise" view of performance across multiple 
20 technology tiers (e.g., web clients, web servers, networks, application servers, database 
servers, storage servers, etc.). The measurement component 102 may measure, for 
example, end-to-end response times from the viewpoint of a user. The measurement 
component 102 may measure segmented response times from tier to tier and may 
therefore indicate the location of performance problems in a particular tier. 

25 

[0032] The performance management system 100 may convert the performance data 
gathered by the measurement component 102 into usage data. The usage data reflects 
actual usage of monitored applications and system resources by particular users or groups 
of users. As will be described in greater detail below, the usage data may be used for 
30 usage-based charge-back. 
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[0033] In one embodiment, a "base" version of the measurement component 102 may 
provide monitoring of a limited set of targets (e.g., TCP/DP-based applications). The 
functionality of the measurement component 102 may be augmented with optional agent 
5 modules that are customized to gather and analyze data for particular targets (e.g., web 
clients, web servers, networks, application servers, database servers, storage servers, etc.). 
For purposes of illustration and example, three agent modules 104a, 106a, and 108a are 
shown. Other combinations of agent modules may be used in other configurations. 

10 [0034] In one embodiment, the discovery component 112 provides identification and 
resolution of root causes of performance degradation. By permitting a user to "drill 
down" through various tiers of hardware and software (e.g., individual servers), the 
discovery component 112 may provide a "depth-wise" view of performance within each 
of the tiers that a target application crosses. The discovery component 112 may further 

15 indicate steps to be taken to fix current problems or avoid future problems. 

[0035] In Figure 1, each of the server blocks 104b, 106b, and 108b within the discovery 
component 112 are intended to represent installations of agent software on the respective 
servers. For example, the three database server blocks 104b represent three agent 

20 software modules associated with three respective database server installations. 
Likewise, the two application server blocks 106b represent two agent software modules 
associated with three respective application server installations, and the four storage 
server blocks 108b represent four agent software modules associated with four respective 
storage server installations. The combination of servers 104b, 106b, and 108b is provided 

25 for purposes of illustration and example and is not intended to be limiting. 

[0036] In one embodiment, the console component 120 includes a "watchdog" layer that 
communicates key performance indicators, such as exceptions to service level agreements 
(SLAs), to appropriate users at appropriate times. The console component 120 may 
30 include functionality 122 for establishing SLAs and other thresholds. The console 
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component 120 may include functionality 124 for reporting and charting. The console 
component 120 may include functionality 126 for providing alerts. Therefore, the 
console component 120 may function as a management console for user interaction with 
the measurement component 102 and discovery component 112. 

5 

[0037] In one embodiment, the performance warehouse 110 includes a repository of 
performance metrics which are accessible to the other components in the performance 
management system 100. The performance metrics may include usage data which reflect 
usage of applications and system resources by particular consumers. The historical data 
10 in the performance warehouse 110 may be used by the other components to provide short- 
and long-term analysis in varying degrees of detail. 

[0038] The performance management system 100 of Figure 1 may be executed by one or 
more networked computer systems. Figure 2 is an exemplary block diagram of such a 

15 computer system 200. The computer system 200 includes a processor 210 and a memory 
220 coupled together by communications bus 205. The processor 210 can be a single 
processor or a number of individual processors working together. The memory 220 is 
typically random access memory (RAM), or some other dynamic storage device, and is 
capable of storing instructions to be executed by the processor 210. For example, the 

20 instructions may include instructions for the performance management system 100. The 
memory 220 may store temporary variables or other intermediate information during the 
execution of instructions by the processor 210. The memory 220 may store operating 
system (OS) software to be executed by the processor 210. 

25 [0039] In various configurations, the computer system 200 may include devices and 
components such as a keyboard & mouse 250, a SCSI interface 252, a network interface 
254, a graphics & display device 256, a hard disk 258, and/or a CD-ROM 260, all of 
which are coupled to the processor 210 by a communications bus 207. The network 
interface 254 may provide a communications link to one or more other computer systems 

30 via a LAN (local area network), WAN (wide area network), internet, intranet, or other 



Atty. Docket No.: 5760-14600 



11 



appropriate networks. It will be apparent to those having ordinary skill in the art that the 
computer system 200 can also include numerous elements not shown in the figure, such 
as additional storage devices, communications devices, input devices, and output devices, 
as illustrated by the ellipsis. 

5 

[0040] Figure 3 illustrates components of a performance management system including a 
business efficiency manager (BEM) according to one embodiment. The BEM may 
integrate usage data from the performance management system 100 with data such as 
licensing information, application cost information, and human resources (HR) 

10 employees directory to provide an overall view of the resource usage and utilization in the 
organization. Using the BEM, an organization's IT department and upper management 
may measure the usage of main business applications, track applications and applications' 
licenses which are not used, analyze usage patterns, plan for server consolidation and 
future investments in infrastructure and applications, and provide a platform for the IT 

15 organization to charge-back organizational units based on the actual employees' usage of 
resources. 

[0041] A BEM server 302 may include an application server and/or a web server for 
performing usage analysis and/or cost allocation tasks. A BEM database 310 may be 
20 used for storage of application and resource usage data, imported data, configuration data, 
management data, and other data used by the BEM server 302 to perform usage analysis 
and/or cost allocation tasks. The BEM server 302 may be referred to herein as a "usage 
analysis and cost allocation server," and the BEM database 310 may be referred to herein 
as a "usage analysis and cost allocation database." 

25 

[0042] A BEM file repository 312 may be used for temporary storage of data by the BEM 
server 302. Data in the BEM file repository 312 may be loaded by the BEM server 302 
into the BEM database 310. In one embodiment, files in the BEM file repository 312 
may be stored as XML files. A BEM console 360 may be used as a client or front-end for 
30 the BEM server 302. In one embodiment, the console 360 may execute browser-based 
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software for tasks such as management of cost allocation tasks, usage measurement and 
analysis, and browsing of usage and cost allocation data. The BEM server 302 and BEM 
console 360 may be implemented using a computer system such as the exemplary 
computer system illustrated by Figure 2. 

5 

[0043] The performance warehouse 110 and usage data server 304 may provide the BEM 
server 302 with usage data collected by the performance management system 100. In one 
embodiment, the BEM database 310 and performance warehouse 110 may be 
implemented using the same database server. In one embodiment, the BEM server 302 
10 and usage data server 304 may be implemented using the same computer system. 

[0044] The BEM server 302 may use input from sources other than resource usage data 
stored in the performance warehouse 1 10. For example, the BEM server 302 may accept 
user input 320. The BEM server 302 may accept imported data (e.g., from external 
15 applications 330). The BEM server 320 may also accept various forms of employee or 
human resources (HR) data 340 from the organizational HR system and end-user or 
information technology (IT) data 350 from the network directory system. 

[0045] Figure 4 illustrates components of a BEM server 302 according to one 
20 embodiment. A usage data importer 410 may import resource usage data from the 
performance warehouse 110 and usage data server 304. An application directory importer 
404 may import the internal user directories of applications. An HR directory importer 
406 may import employee data 340 from HR directories. An IT directory importer 408 
may import data (e.g., LDAP-compatible data) 350 from network directories. A database 
25 access layer 422 may handle access to the BEM database 310 and may isolate the 
business logic from the actual database representation. A database data loader 424 may 
load data to the BEM database 310. 

[0046] The BEM server 302 may include internal processes 418 such as maintenance 
30 operations and self-upgrade. A BEM management component 412 may handle 
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management operations and permissions and may publish a management interface to the 
GUI component or to management consoles. A BEM data retriever 414 may handle data 
access and retrieval according to the permission rules. A GUI and web server component 
402 may handle a presentation layer for a user interface (e.g., at the client console 360). 
5 A file writer 420 may handle write access to the BEM file repository 312. A scheduler 
416 may schedule various operations such as data importing and data loading. In one 
embodiment, tasks may be scheduled to be performed every N hours, every N days or on 
particular days, at a specific time every N days or on particular days, every N weeks, or at 
a specific time and date every N weeks. 

10 

[0047] In one embodiment, configuration of the BEM server 302 may include importing 
employee data 340 from HR directories. The employee data 340 may be used in defining 
organizational units for tracking resource usage and allocating resource costs. In defining 
users within organizational units, the BEM server 302 may match an end-user record 

15 from the usage records with an employee record from the HR directory. The ability to 
match these entities may enable the BEM server 302 to show business views of the usage 
data and assist in implementing a charge-back policy to the various organizational units 
based on usage data. In some cases, the matching of the entities may be straightforward, 
for example, if the application directory already includes a reference to the employee 

20 entity or vice-versa. In other cases, such as web application where the only user identifier 
is an IP address, the BEM administrator may define the matching rules on which the 
BEM server 302 will perform the match. The matching rules may link pairs of imported 
directories and fields within those directories. 

25 [0048] Configuration of the BEM server 302 may also include defining the system 
resources to be tracked. In one embodiment, a BEM administrator may select to employ 
usage-based charge-back for particular resources from a list of resources which are 
monitored by the performance management system 100. In one embodiment, in defining 
the system resources to be tracked for usage-based charge-back, the BEM administrator 

30 may group multiple instances or modules of a particular application into a single resource 
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or keep the instances or modules as separate resources. In one embodiment, the BEM 
administrator may create a hierarchy of elements for a particular system resource. 

[0049] In one embodiment, configuration of the BEM server 302 may also include 
5 entering application licensing information. The licensing information may be entered 
manually or imported automatically. The licensing information may include different 
types of licenses (e.g., different licenses for different applications), the number of licenses 
for each type, and license allocations per employee or per organizational unit. 

10 [0050] The BEM server 302 may provide flexible, configurable usage-based charge-back 
wherein particular organizational units are charged for their consumption of particular 
system resources. The BEM administrator may enter cost elements such as hardware 
costs, software licenses, IT overhead costs, client installation costs, training costs, and 
other suitable costs. In some cases, cost elements may be shared among multiple system 

15 resources. For each cost element, the BEM administrator may define an allocation 
method (i.e., how the cost will be allocated), an allocation context (i.e., to whom the cost 
will be allocated), and a cost. 

[0051] In one embodiment, allocation methods may include per license, per headcount, 
20 per usage time, per active days, per number of activities, and per processing time. Using 
the per license allocation method, the cost is allocated among the employees who have a 
client license associated within the selected allocated context. The same percentage may 
be assigned to each license, regardless of the license type. Using the per headcount 
allocation method, the cost is allocated by the number of employees in the selected 
25 allocation context. Using the per usage time allocation method, the cost is allocated by 
the percentage of the usage time of each employee from the total usage time of the 
employees in the selected allocation context. Using the per active days allocation 
method, the cost is allocated to each employee (in the selected allocation context 
employee group) by the number of days in which he/she worked with the application as a 
30 percentage of the total number of days worked by employees in the selected allocation 



Atty. Docket No.: 5760-14600 



context. Using the per number of activities allocation method, the cost is allocated by the 
number of activities performed by the employee as a percentage of the total number of 
activities performed by employees in the selected allocation context group. Using the per 
processing time allocation method, the cost is allocated by the processing time consumed 
5 by the employee as a percentage of the total processing time consumed by employees in 
the selected allocation context. 

[0052] In one embodiment, shared cost elements may use the allocation methods of per 
license, per headcount, per usage time, per active days, per number of activities, and per 
10 processing time. Non-shared cost elements may use the allocation methods of per license 
and per headcount. License cost elements may use the allocation method of per license. 
In one embodiment, cost models may have a minimum effective time frame (e.g., one 
month). In one embodiment, each system resource may use only one cost model in a 
given time frame. 

15 

[0053] In one embodiment, the resource cost allocations may be calculated on a regular 
basis (e.g., monthly). These regular cost allocations may be stored in the BEM database 
310. Resource cost allocations may also be calculated "on the fly." 

20 [0054] The following resource cost example is presented for purposes of illustration and 
is not intended to be limiting. The example is intended to show a cost allocation for a 
particular system resource for a "sales" organizational unit with a time frame of one year. 
In this example, the particular system resource (e.g., an application) may be defined to 
include: shared cost elements of an application server A01 (cost: $8,000, allocation 

25 method: per usage time), a database (cost: $6,500, allocation method: per usage time), a 
server software license (cost: $10,000, allocation method: per headcount), support (cost: 
$5,000, allocation method: per headcount), and IT management (cost: $6,000, allocation 
method: per headcount); non-shared cost elements of installation (cost: $10, allocation 
method: per license) and training (cost: $10, allocation method: per license); and a license 

30 costs of a full client license (cost: $100, allocation method: per license) and a self-service 
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license (cost: $15, allocation method: per license). 

[0055] For the given year, the organization has 1,000 total employees, 200 employees in 
"sales," 160 employees in "sales" who required installation and training, 10 full client 

5 licenses for "sales," 150 self-service licenses for "sales," 2,000 hours of total resource 
usage time for the entire organization, and 500 hours of total resource usage time for 
"sales." Based on this data and the selected cost allocation model, the "sales" 
organizational unit will be charged a cost of $14,275 for usage of the particular system 
resource in the given year: $2,000 for the application server A01 (500/200 * $8,500), 

10 $1,625 for the database (500/2000 * $6,500), $2,000 for the server software license 
(200/1000 * $10,000), $1,000 for support (200/1000 * $5,000), $1,200 for IT 
management (200/1000 * $6,000), $1,600 for installation (160 * $10), $1,600 for 
training (160 * $10), and $3,250 for license costs of the full client license (10 * $100) 
and the self-service license (150 * $15). 

15 

[0056] Figure 5 is a flowchart which illustrates a method of cost allocation in a computer 
system comprising a plurality of system resources, according to one embodiment. In 502 
a cost is determined for each of the system resources, as discussed in detail above. In 504 
a cost allocation method is determined for each of the system resources, as discussed in 
20 detail above. Each system resource may include one or more cost elements, and each cost 
element may be assigned a cost (e.g., over a particular time frame) and a cost allocation 
method. Steps 502 and 504 may be performed in either order. 

[0057] Resource usage by a particular organizational unit is determined for each of the 
25 system resources in 506. The resource usage may be determined by using a performance 
management system to collect performance metrics for one or more of the system 
resources. The performance metrics may be converted to usage data to reflect actual 
usage of applications and system resources by consumers. In 508 the cost of resource 
usage by the organizational unit is determined based on the cost for each of the system 
30 resources, the cost allocation method for each of the system resources, and the resource 
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usage by the organizational unit for each of the system resources. The cost of resource 
usage by the organization unit may be determined automatically and/or programmatically, 
i.e., by program instructions executed by a computer system. 



5 [0058] As illustrated in Figure 4, the BEM server 402 may include a GUI and web server 
component 402 for generating a graphical user interface (GUI). By interacting with 
various workspaces provided by the GUI, the BEM administrator may perform usage 
analysis. In one embodiment, the BEM GUI may include a resource workspace, an 
organizational unit workspace, a cost workspace, a licenses workspace, and other suitable 
10 workspaces and GUI elements. 

[0059] In one embodiment, the GUI may include a resource workspace which permits the 
BEM administrator to browse usage and cost allocation data for a particular system 
resource over a user-specified time frame. In one embodiment, the resource workspace 

15 may include an application (or resource) usage view, a usage over time view, a usage of 
features view, and a new users view. Figure 6 is a screenshot which shows an example of 
the application usage view according to one embodiment. The application usage view 
may show summarized information such as who is using the resource, usage time by 
organizational unit, average usage time per user in an organizational unit, total number of 

20 activities organizational unit, average number of activities per user in an organizational 
unit, total processing time by an organizational unit, and average processing time per user 
per organizational unit. Figure 7 is a screenshot which shows an example of the usage 
over time view according to one embodiment. The usage over time view may show daily 
and daily average values of the usage parameters across the selected time period (e.g., 

25 concurrent usage, usage time, number of activities and process time total). Figure 8 is a 
screenshot which shows an example of the usage of features view according to one 
embodiment. The usage of features view may show how the various features of the 
application are used. The usage of features view may display a tree view of the 
application (or resource) modules and features, and for each feature, the following data: 

30 number of users (that used the feature), number of licenses available (only when 
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applicable), total usage time and total processing time. Figure 9 is a screenshot which 
shows an example of the new users view according to one embodiment. The new users 
view may show new user entrances to the system by organizational unit, by total users of 
the system, and by the number of licenses for the new users. 

5 

[0060] In one embodiment, the GUI may include an organizational unit workspace which 
permits the BEM administrator to browse usage and cost allocation data for a particular 
organizational unit over a user-specified time frame. In one embodiment, the resource 
workspace may include a usage summary view, an application (or resource) usage view, 

10 and a usage of features view. Figure 10 is a screenshot which shows an example of the 
usage summary view according to one embodiment. The usage summary view may show 
a high level summary of the resources used by the organization unit's employees: e.g., 
which Applications, how many users uses each application, how much time is spent on 
each Application and how many Activities. Figure 1 1 is a screenshot which shows an 

15 example of the application usage view according to one embodiment. The application 
usage view may show statistical data about the applications (or other resources) used by 
the employees of the organization unit (OU): e.g., which resources they used, usage time 
(in hours) by OU, employee average usage time, number of activities per OU, average 
user activities, processing time by OU, average users' processing time, daily visits, and 

20 average daily visits. Figure 12 is a screenshot which shows an example of the usage of 
features view according to one embodiment. The usage of features view may show how 
the various features of all resources are used by the OU. The usage of features view may 
display a tree view of the resource modules and features, and for each feature, the 
following data: number of users (that used the feature), number of licenses available 

25 (only when applicable), total usage time, and total processing time. 

[0061] In one embodiment, the GUI may include a cost workspace which permits the 
BEM administrator to browse cost data over a user-specified time frame. In one 
embodiment, the cost workspace may include a summary view, an application (or 
30 resource) cost view, an organizational unit cost view, and an OU cost analysis view. 
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Figure 13 is a screenshot which shows an example of the summary view according to one 
embodiment. The summary view may show a global view on the cost data: e.g., what 
resources are tracked, how much they cost, and how this cost is distributed to the top- 
level organizational units. Figure 14 is a screenshot which shows an example of the 
5 application cost view according to one embodiment. The application cost view may show 
cost information for one application (or resource): e.g., how the application cost is 
calculated (cost elements, allocation method, allocation target, and element cost) and how 
this cost is distributed to the top-level organizational units. Figure 15 is a screenshot 
which shows an example of the organizational unit cost view according to one 

10 embodiment. The organizational unit cost view may show cost information for an 
organizational unit: e.g., how much the OU is charged for each resource and the 
distribution of this cost in the selected organization down to the employee level. Figure 
16 is a screenshot which shows an example of the OU cost analysis view according to one 
embodiment. The OU cost analysis view may show additional insight to the information 

15 shown in the organizational unit cost view: e.g., (total) average employee cost for each 
sub-OU under the selected organization unit as well as application specific average cost 
per employee. 

[0062] In one embodiment, the GUI may include a licenses workspace which permits the 
20 BEM administrator to browse license data over a user-specified time frame. In one 
embodiment, the license workspace may include a summary view, a license utilization 
view, and an unlicensed usage view. Figure 17 is a screenshot which shows an example 
of the summary view according to one embodiment. The summary view may show a 
global view of the licensing data: e.g., which licenses were entered to the BEM server 
25 302, which license types, and high level allocation to organization units. Figure 18 is a 
screenshot which shows an example of the license utilization view according to one 
embodiment. The license utilization view may show the license utilization of a selected 
application in an OU. The license utilization view may allow the BEM administrator to 
define the metric that will be used to analyze the license utilization (e.g., selected from: 
30 Usage Time per User, Number of Activities per User, Total Processing time per User and 
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Daily Visits per User) and the values for heavy, medium, and low usage. Figure 19 is a 
screenshot which shows an example of the unlicensed usage view according to one 
embodiment. The unlicensed usage view may show whether there are more users than 
licenses entered to the system. The unlicensed usage view may show an overview 
5 licensing picture and, for each sub-OU for the selected organizational unit, how many un- 
licensed users for each resource. 

[0063] It is further noted that any of the embodiments described above may further 
include receiving, sending or storing instructions and/or data that implement the 

10 operations described above in conjunction with Figs. 1-19 upon a computer readable 
medium. Generally speaking, a computer readable medium may include storage media or 
memory media such as magnetic or optical media, e.g. disk or CD-ROM, volatile or non- 
volatile media such as RAM (e.g. SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), 
ROM, etc. as well as transmission media or signals such as electrical, electromagnetic, or 

15 digital signals conveyed via a communication medium such as network and/or a wireless 
link. 

[0064] Although the embodiments above have been described in considerable detail, 
numerous variations and modifications will become apparent to those skilled in the art 
20 once the above disclosure is fully appreciated. It is intended that the following claims be 
interpreted to embrace all such variations and modifications. 
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